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FINANCIAL INSTITUTION-BASED TRANSACTION 
PROCESSING SYSTEM AND APPROACH 



5 Field of the Invention 

The present invention is directed to communications and data processing and, more 
specifically, to communications and data processing involving transaction-related financial 
processing. 

10 Background 

Operational management of contractual and transactional interactions between 
buyers, sellers, financial institutions and others involved in the exchange of products for 
purposes of commerce have typically been labor and time intensive. Generally, the 
processes of managing transactions between business entities have been unduly burdensome 

15 and inefficient 

Financial institutions employ transaction processing parameters that are unique to 
each institution. In addition, these transaction processing parameters typically need to be 
kept separate (and confidential), relative to other financial institutions. Often, transaction 
processing is dependent upon these parameters, which are specific to a particular financial 

20 institution involved in financing the transaction. In this regard, transaction processing for 
portions of a transaction that are related to a financial institution has generally been limited 
to implementation by a processing engine or system employed by the financial institution 
participating in the transaction. 

When a transaction reaches the payment step, financial institutions for different 

25 parties to the transaction must interact with each other. This interaction typically involves 
complex agreements and associations that facilitate the transfer of funds. At times, there 
can be delays in payment or disputes regarding terms of payment. In addition, this process 
is highly susceptible to error. Interaction complexity, delay and error, as well as a multitude 
of other characteristics of transaction payment can cost one or more parties to a transaction 

30 (including financial institutions) a significant amount of funds. 

Most industries are quite competitive and any cost savings are therefore important. 
Administrative costs are targeted for reduction as no revenue is directly generated from 
administrative functions. However, administrative costs associated with commercial 
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transactions have been difficult to reduce in the current business environment with widely 
diffused data. 

The above and other difficulties in the management and coordination of financial 
transactions have presented administrative and cost challenges to entities involved in 
5 various aspects of transactions, including financial institutions and others. 

Summary 

The present invention is directed to overcoming the above-mentioned challenges and 
others related to the types of devices and applications discussed above and in other 
10 applications. The present invention is exemplified in a number of implementations and 
applications, some of which are summarized below. 

According to an example embodiment of the present invention, financial 
transactions involving financial institutions are managed using an approach generally 
involving the use of rules for processing payment-related aspects of the financial 
15 transactions. 

In a more particular example embodiment of the present invention, a transaction 
management system is configured for using sets of rules associated with financial 
institutions for processing transactions. When transaction information is received, it is 
associated with a particular sponsoring financial institution. Rules for the sponsoring 

20 institution are used to process the transaction. In some instances, the rules are further 

selected and implemented as a function of one or more of the sponsored transaction parties 
(e.g. , a buyer or seller). 

In another example embodiment of the present invention, an automated transaction 
processing system is adapted for processing transactions involving a plurality of financial 

25 institutions. The system includes a central processing node adapted to audit (e.g., validate 
or otherwise approve) transactions between contracting parties according to different sets of 
transaction rules. Each of the respective sets of transaction rules are defined as a function of 
a unique one of the plurality of financial institutions and a relationship between the unique 
financial institution and at least one of the contracting parties. 

30 According to another example embodiment of the present invention, an automated 

transaction processing system audits transactions between contracting parties on behalf of a 
plurality of financial institutions. The automated transaction processing system includes a 
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central processing node adapted, for different transactions involving various financial 
institutions, to associate each transaction with a unique one of the plurality of financial 
institutions and to audit each associated transaction according to a set of transaction rules. 
These transaction rules are defined as a function of the unique financial institution and a 
5 business relationship between the unique financial institution and at least one of the 

contracting parties. In this regard, the audit involves using information in the rules, upon 
which payment can be authorized, and comparing or otherwise processing information for a 
particular transaction (e.g., receipt of goods, issuance of an invoice) to approve payment for 
the transaction (or deny payment where transaction information fails to satisfy payment- 
10 type conditions). The central processing node facilitates payment for each transaction as a 
function of the audit. 

The above summary of the present invention is not intended to describe each 
illustrated embodiment or every implementation of the present invention. The figures and 
detailed description that follow more particularly exemplify these embodiments. 

15 ■ 

Brief Description of the Drawings 

The invention may be more completely understood in consideration of the detailed 
description of various embodiments of the invention in connection with the accompanying 
drawings, in which: 

20 FIG. 1 shows a transaction processing arrangement, according to an example 

embodiment of the present invention; 

FIG. 2 shows an arrangement and approach for transaction management, according 
to another example embodiment of the present invention; and 

FIG. 3 shows a flow diagram for transaction processing, according to another 
25 example embodiment of the present invention. 

While the invention is amenable to various modifications and alternative forms, 
specifics thereof have been shown by way of example in the drawings and will be described 
in detail. It should be understood, however, that the intention is not necessarily to limit the 
invention to the particular embodiments described. On the contrary, the intention is to 
30 cover all modifications, equivalents, and alternatives falling within the spirit and scope of 
the invention as defined by the appended claims. 
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Detailed Description 

The present invention is believed to be applicable to a variety of different types of 
communications and financial process management approaches, and has been found to be 
particularly useful for applications involving the operational implementation and application 
5 of financial institution rules and processes with transactions, payments, tracking and related 
aspects thereof. While the present invention is not necessarily limited to such approaches, 
various aspects of the invention may be appreciated through a discussion of various 
examples using these and other contexts. 

According to an example embodiment of the present invention, a financial rules- 

1 0 based transaction approach is implemented with multiple sponsoring financial institutions 
for automatically processing financial transactions. The sponsoring financial institutions 
sponsor transaction parties (e.g., buyers and sellers); financial aspects of transactions 
between two or more of the sponsored transaction parties are carried out as a function of 
business rules for the financial institution sponsoring each party. 

15 In another example embodiment of the present invention, a central transaction 

management system uses business rules (e.g., included in profile information) associated 
with financial institutions to process financial transactions between parties sponsored by the 
financial institutions. When the central transaction management system receives transaction 
information, the information is parsed for identifying characteristics that can be associated 

20 with sponsoring financial institutions. When these identifying characteristics match a 
particular financial institution, the central transaction management system uses business 
rules for the financial institution to process the financial transaction. In addition, when 
identifying characteristics for different parties to the transaction match different financial 
institutions, financial aspects of the transaction that are specific to each party are processed 

25 according to the each party's corresponding sponsoring financial institution. Funds relating 
to the financial transaction are thus transferred according to the business rules associated 
with sponsoring financial institutions for each party and to the particular characteristics of 
the financial transaction. 

In one implementation, the central transaction management system audits data for 

30 transactions between the different parties as a function of business rules for one or more of 
the transaction parties. For example, where a particular party specifies conditions, in its 
business rules, upon which payment can be authorized, the central transaction management 
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system implements those conditions in connection with the audit and determines therefrom 
a condition of payment for the transaction (e.g., whether some or all of a particular invoice 
can be paid). As another example, different parties to a contract may specify rules upon 
which transaction data is to be audited to indicate that the transaction is valid and/or ripe for 
5 payment. This auditing may include, for example, setting a price for a particular 

transaction, such as setting the price for a shipment involving bill of lading (BOL) rating or 
setting the price for a transaction based on characteristics of the transaction such as quantity 
of goods and/or receipt of the goods. In another example, the auditing involves comparing 
terms in transaction data from an electronic invoice to previously agreed upon contract 
10 terms; where the invoice matches the terms, or is within a tolerance where specified, the 
auditing results in an approval (i.e., validation of the transaction) for payment of the 
invoice. A multitude of such auditing approaches can selectively be implemented, based on 
various terms set by different -transaction parties, by sponsoring financial institutions or 
other related entities. 

15 In another implementation, the central transaction management system further uses 

business rules associated with individual parties to a transaction in processing financial 
transactions involving the individual parties. For instance, when the central transaction 
management system receives transaction information, the information is parsed (as 
discussed above) to identify sponsoring financial institutions as well as the parties to the 

20 transaction. . The transaction is then process according to the business rules of the 
sponsoring financial institutions as well as the business rules of the parties to the 
transaction. These party-specific business rules may be stored, for example, in a user 
profile that is accessible by the central transaction management system. The user profiles 
may include identifiers used to identify buyer or seller transaction parties and/or sponsoring 

25 financial institutions. 

In some instances, the sponsoring financial institution for a particular party is 
identified as a function of the identity of the party and corresponding business rules for the 
party. For example, when a party sets business rules to identify a particular sponsoring 
financial institution, these business rules are implemented in selecting the sponsoring 

30 financial institution. Correspondingly, the business rules for the financial institution 
identified by the party's business rules are used to process the financial transaction. 
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In other instances, two or more financial institutions can be specified by a particular 
party, including sponsoring and/or non-sponsoring financial institutions. Business rules for 
the particular party may include financial institution selection criteria that is implemented as 
a function of the particular transaction. For instance, selection criteria may be configured to 
5 indicate that payment for transactions under a certain value be processed (financed) using a 
first financial institution, while payment for transactions at or over the certain value be 
processed using a second financial institution. This approach may be implemented, for 
example, where large value transactions that may involve a longer payment period are 
desirably financed through a financial institution offering terms that are practicable for 

1 0 maintaining a longer payment term (z. e. , lower rates). Small value transactions typically 
involving a shorter (or no) payment term may preferably be serviced using a financial 
institution offering desirable services or low service fees, but higher rates. 

Sponsoring financial institutions may implement criteria similar to that discussed in 
the paragraph above for selecting a particular institution via which to process transactions, 

15 with selected criteria being implemented for making such selections. This approach may be 
useful, for example, where parties to the transaction agree to use a financial institution 
selected by the sponsoring financial institution that sponsors the party into the automated 
' transaction process. In this regard, the financial institution selected for providing payment 
for a particular transaction is selectively different than the sponsoring financial institution. 

20 Such a financial institution may be selected by the sponsoring financial institution using, for 
example, a geographical location of a seller to which payment is to be made. 

In some implementations, the central transaction management system works to keep 
separate the transaction rules for each financial institution (and transaction parties, where 
appropriate). Access to the transaction rules is restricted to the institution (or party) to 

25 which the rules belong. This restricted access approach may be implemented using, for 
example, encryption, passwords, tracking and other security-type measures typically 
implemented for data access and protection. 

In some applications, a data access controller facilitates the restriction of access to 
transaction information by providing access to each financial institution for data relating to 

30 their clients. The data access controller selectively facilitates access via an overview type of 
data presentation that shows a financial overview for each customer to whom the financial 
institution issues credit. For example, for buyer customers, the data access controller 
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selectively implements an overview showing each buyer's net position between payments 
due from the buyer and payments due to sellers (suppliers) through the transaction 
processing system. 

In another application, the data access controller discussed above is further 
5 configured and arranged, for each sponsoring financial institution, to perform customer 
service functions related to transaction processing for the financial institution's customers 
within the transaction processing system. Such customer service functions are defined in 
the sponsoring financial institution's business rules in association with each customer. The 
data access controller implements the business rules in performing the customer service 
10 functions. 

Business rules used by the central transaction management system may be stored 
using one or more of a variety of approaches. For example, a database accessible by the 
central transaction management system and having labels or other identifying characteristics 
that associate the business rules with a particular financial institution can be used. This 

1 5 database can be physically local or remote to the central transaction management system, as 
long as the central transaction management system can access the database and control 
access to the database by other entities. 

The central transaction management system is further configured to interface with 
financial institutions for a particular transaction party, in addition to a sponsoring financial 

20 institution for the transaction party. For instance, where a transaction party has primary 
banking functions with a non-sponsoring financial institution, the sponsoring financial 
institution, via the central transaction management system, facilitates the transaction by 
exchanging funds via the non-sponsoring financial institution. The sponsoring financial 
institution may further implement processing type fees via the central transaction 

25 management system, charged for facilitating the financial transaction. 

In some instances, the central transaction management system interfaces directly 
with financial institutions that, from a hierarchical perspective, pass-through information 
received from one or more parties to the transaction. The central transaction management 
system uses transaction rules based on the transaction information received from a financial 

30 institution. Effectively, the financial institutions use the central transaction management 
system to execute transaction-processing functions that are carried out using transaction- 
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based rules specific to the particular financial institution providing the transaction 
information. 

In other instances, the central transaction management system is adapted to interface 
directly with parties to a transaction and to use transaction rules based on information 
5 received from one or more of the parties (/. e. , without a sponsoring financial institution). 
For example, a buyer or seller can interface with the central transaction management system 
using rules, implemented with the system, which are based on profile information for the 
particular buyer or seller. These parties may contract with a system administration entity, 
effectively acting as a sponsoring financial institution in some regards, relative to the above 

1 0 discussion, to facilitate transactions in this manner. 

According to another example embodiment of the present invention, a central 
transaction management system uses transaction information for buyers and sellers of 
products and/or services to automatically derive pricing and/or payment options for 
individual transactions. These products and services may include, for example, tangible 

15 goods, shipment services, consulting services and financial services (e.g., where the seller 
may be a financial institution selling a financing package for a transaction between a buyer 
and another seller). The transaction information may include, for example, the identities of 
the buyer and seller, the products and/or services being purchased, the date of the purchase 
and the specific contract under the terms of which the transaction is being executed. For 

20 instance, specific contracts under the terms of which a transaction is being prosecuted may 
include prices agreed upon between a buyer and seller for a particular product and/or 
service. 

Transaction-related contracts facilitated by the central transaction management 
system may also (or in the alternative) include rules agreed upon for setting certain financial 

25 and/or price terms between a buyer and seller. In one instance, terms associated with a 

particular transaction are automatically set by the central transaction management system to 
correspond to transaction information assigned to a particular buyer.; The terms may be set, 
for example, using predetermined terms agreed to by the buyer and seller involved in the 
transaction. In another implementation, pricing arrangements such as quantity discounts, 

30 group discounts and conditional price variances (e.g., an acceptable percentage of variance 
in cost associated with for fluctuating shipping costs, product prices, financing costs and 
others) are further automatically implemented in response to the transaction information and 
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the approved contract details in the central transaction management system. In still another 
implementation, financing terms such as processing fees for facilitating a transaction, 
interest-related fees, credit-extension fees and others are automatically set as a function of 
such a transaction-related contract. Where credit is extended, a rating engine is optionally 
5 implemented to assign an interest rate to an applicable transaction, for extending credit on 
behalf of a contracting party to the transaction. 

Turning now to the figures, one or more of the above-discussed approaches are 
selectively implemented in connection with the processors and other functions shown in the 
figures and discussed as follows. Beginning with FIG. 1, a transaction processing 

10 arrangement 100 includes a central transaction processor 1 10 programmed to automatically 
process transaction information according to business rules corresponding to particular 
financial institutions, according to another example embodiment of the present invention. 
When transaction information is received at the central transaction processor 110, the 
information is associated with sponsoring financial institutions for each party to the 

15 transaction and processed according to business rules for the sponsoring financial 

institutions. The central transaction processor 110 may be implemented, for example, in 
connection with the above-discussed approaches including those involving the discussion of 
a central transaction management system and/or with a central transaction node in a network 
node-based arrangement. 

20 Business rules are supplied by a multitude of financial institutions employing the 

central transaction node 1 10, represented here by financial institution nodes 120 and 128. 
In some instances, parties involved in transactions facilitated by the central transaction node 
also supply business rules. The central transaction processor 1 10 is in communication with 
a database 112 where transaction-related information including the above-discussed 

25 financial institution rules is stored. The database 1 12 is optionally coupled to (or part of) 
the central transaction processor 110 and further may include a plurality of data storage 
arrangements at different locations. The central transaction node 110 maintains separate 
(and secure) storage for these business rules by restricting access to the rules by the 
financial institutions (or others such as transaction parties). 

30 The central transaction node 1 10 is further adapted to communicate with a variety of 

different parties to a transaction, represented by transaction parties 122, 124 and 126. These 
transaction parties and the financial institutions represented by user nodes 120, 122, 124, 
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126 and 128 are communicatively coupled with the central transaction processor 110. The 
user nodes 120-128 may, for example, include one or more of a buyer, seller, distributor, 
shipper, carrier, government agency, financial institution or other type of individual, group 
or agency that would be involved in a transaction, with parties shown in the figure by way 
5 of example. 

The nodes 120-128 interact with the central transaction processor 1 10 for providing 
transaction-related information, such as financial processing rules, accounting rules, orders, 
invoices, shipping documents, payment authorization data, payment execution data, customs 
documents, security documents and others. In addition, this transaction-related information 

10 may include information for relating the application of rules to transaction data, such as 
payment processes, credit extension and finance charges. In some instances, financial 
institution nodes provide rules that are stored in the database 112, with other party nodes 
simply interacting with the central transaction node 110 (e.g. , without providing any 
information for storage in the database 1 12). Transactions are thus processed as a function 

1 5 of stored rules for a particular financial institution (or institutions) with which the 

transactions are associated. In other instances, the database 1 12 is also implemented for 
maintaining transaction party-type information, such as user preferences (e.g. , reporting, 
billing, credit extension) and financial institution preferences (e.g., which institution to use). 
The transaction parties 122, 124 and 126 may be implemented via sponsoring 

20 financial institutions, with nodes 122, 124 and 126 representing this combination of 

transaction parties with a particular sponsoring financial institution. This combinatorial 
representation may also maintain direct interaction between transaction parties and the 
central transaction node 1 10 for facilitating party-specific communications, such as for 
setting business rules or profile information for individual parties. 

25 In some implementations, one or more of the nodes 120-128 are used as interfaces to 

the central transaction processor 110, with users at the nodes being able to provide 
transaction-related information such as classification rules. In other implementations, the 
central transaction processor 110 automatically accesses information from the user nodes 
for a variety of purposes, such as retrieving classification rules (e.g., accounting codes 

30 and/or business rules) or updating related accounting fields. This interaction between the 
nodes and the central transaction processor 1 10 is controlled using, for example, access 
authorization such as those involving password-protected authorization and others. 
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When transaction data is received at the central transaction node 1 10 for financial 
institution-type processing, the central transaction node parses the data and automatically 
associates the transaction data with a particular financial institution sponsoring the 
transaction to which the data applies. This automatic association is implemented using 
5 business rules in the database 1 12 and/or as a function of the node sending the transaction 
data. In some instances, profile information for various sponsoring financial institutions 
(and/or transaction parties) is stored in the database 1 12 and used in connection with 
identifiers in received transaction information to automatically associate the transaction 
information with sponsoring financial institutions. The central transaction node 110 

10 processes the associated data according to applicable business rules that may be tailored, for 
example, to a particular type of transaction or to particular transaction characteristics. 

Where credit is extended on behalf of users, the central transaction processor 110 
selectively assigns an interest rate to the extension of credit, either directly wherein an 
administrator of the central transaction processor extends credit, or in connection with an 

1 5 interest rate offered by a financial institution extending the credit. In some applications, the 
central transaction processor 110 implements a rating engine to assign an interest rate to an 
applicable transaction, for extending credit on behalf of a contracting party to the 
transaction. The rating engine uses information about the contracting party in order to 
establish such an interest rate. 

20 In another example embodiment, the central transaction processor 1 1 0 is further 

adapted to grant and control information exchange with the database 1 12 as a function of 
inputs received from the nodes 120-128, such as authorization inputs and transaction- 
specific inputs. When users at one of the nodes 120-128 attempt to send information to or 
retrieve information from the central transaction processor 110, authorization information 

25 from the users is used to control the information transfer. The authorization information 
may include, for example, access-type information (e.g., a password or user ID) or simply 
document information that the central transaction processor 110 recognizes. 

In another example embodiment, the central transaction processor 110 maintains 
data for business rules and processed transactions over time for a variety of purposes, such 

30 as for generating reports, tracking compliance and for taking appropriate action where errors 
or non-compliance occurs. For example, when a particular transaction is processed or when 
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business rules are changed, the central processor monitors associated information and stores 
and/or processes the monitored information for these purposes. 

The user profiles and/or business rules discussed herein in connection with FIG. 1 
above and otherwise may include a variety of information for use in transaction 
5 management and financial processing. For instance, in addition to the above-discussed 
approaches, a typical such profile may include one or more of the following data: general 
ledger charts of accounts, identification of computer systems submitting contract or 
transaction data, customer lists, vendor lists, financial institution lists, contract and price 
approval policies, transactional approval policies, business rules, operational roles (e.g., 

10 defining what functions a user associated with that role can perform), organizational 

hierarchy (e.g. , defining how much of a company's data a user associated with a particular 
organizational node can access), and individual users. Financial institution profiles may 
also include information further defining the business relationship with selected customers 
or other financial institutions and financial processing organizations from the financial 

15 institution's perspective. 

FIG. 2 shows an arrangement and approach for transaction management in an 
automated transaction network, according to another example embodiment of the present 
invention. A transaction processing system 210 interfaces with a plurality of financial 
institutions for facilitating transactions, using data stored in a database 220 for 

20 implementing rules for the transactions. These rules are used to process financial aspects of 
the transactions, relative to information received via sponsoring financial institutions. 

Two sponsoring financial institutions (230 and 240) are shown, with multiple such 
institutions being contemplated but not shown for brevity. Each sponsoring financial 
institution 230 and 240 works with multiple users, represented as users 1-N for institution 

25 230, and users A-i for institution 240. Communications between the sponsoring financial 
institutions and the transaction processing system 210, as shown by communication links, 
may be implemented directly from the sponsoring financial institutions. In addition, the 
shown communication links may represent a direct communication from a sponsored user, 
the user including in the communication sufficient information (and security type 

30 information, where appropriate) to designate the appropriate sponsoring financial 
institution. 
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The transaction processing system 210 also interfaces with a variety of funds 
processing originators. By way of example, automatic clearing house (ACH) originators 
250 and 270, and SWIFT (a European-based, straight through processing (STP) transaction 
system) originators 260 and 280 are shown. These funds processing originators are 
5 typically implemented as financial institutions having appropriate funds processing 

capabilities for implementing, for example, ACH or SWEFT-type functions. In this regard, 
the transaction processing system 210 interfaces with financial transaction processing 
entities for obtaining authorization to proceed with a transaction and to coordinate fund 
transfer using the respective originators (Le. 9 as conventional). The transaction processing 

1 0 system's interface with ACH and other providers is selectively specified by business rules 
used in processing a particular transaction for payment and facilitation functions. 

The business rules in database 220 typically include user-specified rules that are 
provided by the financial institutions using the transaction processing system 210 for 
processing financial transactions. For example, user profile information for each sponsoring 

1 5 financial institution can be stored in the database 220 for use by the transaction processing 
system 210. This profile information may include, for example, business rules specifying 
one or more various conditions or approaches related to financial transaction processing, as 
discussed herein. For more information regarding transaction processing in general, and for 
specific information regarding the use of user profiles and business rules for transactions, as 

20 well as computer and processing arrangements and systems for use with the same (and as 
may be implemented in connection with one or more example embodiments herein), 
reference may be made to U.S. Patent Application Serial No. 10/436,878 (USBA.101PA), 
entitled "Automated Transaction Processing System and Approach" and filed May 12, 
2003, and to U.S. Patent No. 5,910,896 (USBA.002PA) filed November 12, 1996, all of 

25 which are incorporated herein by reference. 

When the transaction processing system 210 receives transaction data identifying a 
particular sponsoring financial institution, the database 220 is accessed to retrieve profile 
information (and corresponding business rules) for processing the transaction data. The 
business rules are used to determine a variety of transaction-related characteristics, such as 

30 fees to be charged for different parties to the transaction, including buyer, seller and their 
respective financial institutions. Additional rules-based processing examples are discussed 
further below. 
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The storage of information in the database 220 may involve the use of a single 
database, or may involve multiple databases, either in a single or at multiple locations, 
communicatively coupled with the transaction management system 210. In one 
implementation, all transaction data for all buyers and sellers sponsored by all financial 
5 institutions is stored in one centralized database. The transaction management system 210 
manages the centralized database such that information in the database that has a common 
relationship with other information in the database can be cross-referenced and updated. 
For instance, where information for a buyer and seller for a single transaction is stored in 
the centralized database, updates made to the buyer's information can be appropriately 

10 made to similar seller's information. This approach can be implemented to ensure that any 
buyer and any seller can do business with each other and see up-to-date status and 
documents without latencies typically involved attempting to replicate and synchronize data 
across multiple databases. 

Business rules stored in the database 220 are optionally tailored to particular users 

1 5 that are being sponsored by the financial institution. In this regard, the business rules 
pertaining to a particular sponsoring financial institution, as well as the user being 
sponsored for a particular transaction, are retrieved from the database 220 and used 
accordingly. In some instances, sponsored users also store profile information in the 
database 220, such as preferred banking institution (i.e., with the sponsoring financial 

20 institution simply sponsoring the transaction for a fee and not funding the transaction). 

In some instances, the transaction processing system 210 includes two or more 
system implementations, represented by system implementations 1 and 2 - N. These system 
implementations may involve virtually separate implementations at a single location to 
facilitate data security and continuity for particular sponsoring financial institutions. For 

25 instance, each system implementation may be implemented for a particular financial 

institution, with communication between each system implementation and other system 
implementations being facilitated within the transaction processing system 210. In this 
regard, each user (sponsoring financial institution) may tailor it's specific system 
implementation to its own needs. 

30 The system implementations with transaction processing system 210 may also be 

implemented at physically separate locations, with virtual ties to the transaction processing 
system 210. For example, the implementation of various aspects of the transaction 
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processing system may be appropriate for applications in different countries or for point-of- 
use type applications (e.g., to reduce long distance data communications). This physically 
separate approach may also be implemented, for example, to address laws associated with 
transactions, including taxation and other processing rules. 
5 As discussed above, various business rules stored at the database 220 are 

implemented by the transaction processing system 210 for a variety of transaction 
characteristics. One such characteristic involves the determination of fees to be charged to 
users (buyers and sellers), to sponsoring financial institutions and, where applicable, to 
other financial institutions involved in the transaction. In this regard, the database 220 
1 0 stores business rules characterizing these fees, and the transaction processing system 210 
uses these characterizing business rules to process financial transactions. In addition, the 
database 220 may store party-identifying information for use by the fee-based rules in 
characterizing the fees to be assessed for a particular transaction. 

In some applications, the business rules are implemented to arrive at a collaborative 
1 5 transaction term, such as a price or other term automatically implemented as an agreed-upon 
term by using previously agreed-upon business rules for generating such a term. Fee-based 
rules implemented in connection with these approaches may involve, for example, 
information for determining the amount of fees to assess for one or more of the following: 
fees to be charged to the seller for the transaction based on the identity of the seller 
20 and the identity of the seller's sponsoring bank; 

fees to be charged to the buyer for this transaction based on the identity of the buyer 
and the identity of the buyer's sponsoring bank; 

fees the seller's sponsoring bank owes the buyer's sponsoring bank for this 
transaction; 

25 fees the buyer's sponsoring bank owes the seller's sponsoring bank for this 

transaction; and 

fees the buyer's sponsoring bank and the seller's sponsoring bank owe the 
transaction processing system 210 for this transaction. 

These collaborative type terms and approaches for implementing the same are 
30 selectively carried out using, for example, the transaction processing arrangement 100 
shown in FIG. 1 and/or the transaction processing system 210 shown in FIG. 2, with 
transactions involving buyers and sellers sponsored into the processing network by a 
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sponsoring bank. In these approaches, for each of a plurality of transactions involving a 
buyer and a seller, an association processor 212 identifies a particular sponsoring bank for 
each buyer and seller as a function of stored identifiers. The association identifies 
respective business rules, set in accordance with the particular sponsoring bank and the 
5 particular buyer or seller for which the rules are set, for respectively processing transactions 
on behalf of the buyer and on behalf of the seller for a particular transaction. These and 
other association processor 212 functions can be implemented separately from or in 
connection with {e.g., as a software-implemented function) the transaction processing 
system 2 10. 

10 In some applications, the association processor facilitates the identification of 

business rules using a geographic location of a party to the transaction, for example where 
transaction payment characteristics are affected by such a location {e.g., where tariffs and/or 
taxes are involved). 

In other applications, the association processor identifies business rules for a 

1 5 sponsoring financial institution using historical information for a particular transaction 

party. For example, where a financial institution implements different sets of business rules 
based on payment characteristics, credit rating, business volume or other historical-type 
information pertaining to a transaction party, that information is used to select a set of 
business rules to use in facilitating a transaction involving the transaction party. 

20 A collaborative contracts processor uses the identified business rules and a business 

agreement between the buyer and seller to determine the amount of fees assessed in 
accordance with one or more of the above fees discussed in connection with the fee-based 
rules. Other approaches involving a collaborative contracts approach are discussed further 
below. 

25 Turning back to FIG. 2 and with approaches involving the above assessed fees, the 

transaction processing system 210 uses information in profiles for facilitating the transfer of 
funds from, or the extension of credit on behalf of, the entity to which fees are assessed. 
For instance, where a particular fee is to be assessed against sponsoring financial institution 
230 and/or one of the users 1 -N, funds from that institution are provided directly {e.g., 

30 funds transfer) or indirectly {e.g. , extension of credit), from the sponsoring financial 

institution 230 or from another financial institution specified by the user, where applicable. 
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The user (e.g., buyer, seller and financial institution) profiles discussed herein and 
implemented with collaborative-type approaches may include a variety of information for 
use in transaction management and otherwise. In some applications, typical profiles include 
one or more of the following data: a general ledger chart of accounts, identification of a 
5 computer system authorized for submitting contract or transaction data, customer and/or 

vendor lists, policies for contract, price or transactional approval and business rules. Where 
individuals within an organization participating in the collaborative-type approaches are 
selectively authorized, operational roles for such users are defined and include, e.g., access 
authorization for the users as well as individual access tracking. Seller customer list profiles 

1 0 may also include information further defining the business relationship with the customer 
from the Seller's perspective, for example, such as a retail buyer relationship or a wholesale 
buyer relationship. List profiles for buyers who act as vendors (e.g. , as a seller or 
distributor) may also include information further defining the business relationship with the 
vendor from the Buyer's perspective. 

15 In one particular implementation, profile information such as business rules, 

operational roles, authorization levels and/or other attributes are specific to particular levels 
and/or individuals within a particular entity. This profile information is stored for access by 
the transaction processing system 210 and used for implementing transactions. For 
example, when a particular financial institution or sponsored user includes different 

20 subsidiaries, divisions or locations, profile information can be tailored for the particular 
source. Certain profile information can also be implemented to supersede other profile 
information, for example, when a particular subsidiary is assigned different specific pricing 
terms, relevant to another subsidiary of a common entity. 

In another example embodiment facilitating collaborative approaches, the 

25 transaction processing system 210 stores information for transaction parties including one or 
more of financial institutions and sponsored users (e.g., buyers and sellers), and 
communicates therewith using an identification approach for users at the buyer and/or seller 
level. The transaction processing system 210 controls access to the stored information as a 
function of user identification (ID), with access parameters controlled for processes such as 

30 contract modification, price modification, display configuration, access to the stored 
information for that particular user and others. 
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As an example using seller offerings that make up at least part of the stored 
information for a particular seller as well as buyer access controls, the seller offerings are 
automatically configured for usage by the individual users. In this context, seller offerings 
may involve real goods and/or services, as well as or in the alternative to financial offerings, 
5 such as the extension of credit and/or financial processing services. The automatic 

configuration may, for example, include price, delivery and payment options. In response 
to the seller offerings and other stored information, the transaction processing system 210 is 
adapted for accepting requests from buyers and communicating the requests to the seller. 
The transaction processing system 210 is further adapted for accepting acknowledgment of 

10 receipt by the buyer either manually (e.g., an individual buyer logs into the system with a 
user ID and confirms receipt) or electronically (e.g., buyer's inventory receiving systems 
automatically generate and transmit a detailed notice of receipt or acceptance). Once 
receipt or acceptance is acknowledged, the system communicates that acknowledgment to 
the seller. In one implementation, the system is further adapted for automatically paying the 

15 seller in response to the receipt/acceptance acknowledgment. In another implementation, 
the system is further adapted to invoice the buyer for the offerings. Further, "payment" in 
this context may involve the drawdown of a credit line, or extension of credit in manners as 
appropriate for the particular transaction. 

In some applications, the transaction processing system 210 implements a settlement 

20 processor 214 in connection with facilitating payment for a particular transaction between a 
buyer and a seller. The settlement processor 212 performs inter-bank settlement by 
calculating the amount of funds to be collected from a sponsoring bank for the buyer and 
remitted to a sponsoring bank for the seller. The settlement is used to fund a payment that 
the seller's sponsoring bank will make to the seller for all transactions that achieve payable 

25 status, e.g., within a payment period defined as a function of the business rules. 

The settlement processor 214 is implemented to facilitate payment/settlement in a 
variety of manners, depending upon the application and appropriate contract terms and other 
information relative to the truncation parties and/or sponsoring financial institutions 
involved in a particular transaction. In this regard, some applications involve one or more 

30 of the following electronic payment approaches as facilitated by the settlement processor 
214 for a transaction involving a buyer and a seller, with sponsoring banks for each. In one 
approach, the settlement processor 214 facilitates the submission of an electronic payment 
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demand at a defined period to the buyer's sponsoring bank for all net monies due to at least 
one of the transaction processing system and the seller's sponsoring bank, when the buyer's 
sponsoring bank is in a net funds due (to the transaction processing system) position. In 
another approach, the settlement processor 214 facilitates the submission of an electronic 
5 payment demand at a defined period to the seller's sponsoring bank for all net monies due 
to at least one of the transaction processing system and the buyer's sponsoring bank, when 
the seller's sponsoring bank is in a net funds due position. In another approach, the 
settlement processor 214 facilitates the submission of an electronic payment notice at a 
defined period to the buyer's sponsoring bank for all net monies due to the buyer's 

10 sponsoring bank, after subtraction of fluids due to at least one of the transaction processing 
system and the seller's sponsoring bank, when the buyer's sponsoring bank is in a net funds 
due to processor position. In still another approach, the settlement processor 214 facilitates 
the submission of an electronic payment demand at a defined payment period to the seller's 
sponsoring bank for all net monies due to the seller's sponsoring bank after subtraction of 

1 5 funds due to at least one of the transaction processing system and the buyer's sponsoring 
bank, when the seller's sponsoring bank is in a net funds due to processor position. In each 
of the above approaches, the net funds due to processor position selectively characterizes 
funds due, and in certain applications, characterizes funds due to an administrator of the 
transaction processing system 210 for transaction payment (e.g., from a buyer to a seller) 

20 and/or for fees associated with the processing of the transaction payment. 

In another implementation, the transaction management system discussed in the 
preceding paragraph is further adapted for accepting a receipt of purchase acknowledgment 
including receipt characteristics. For example, characteristics such as total acceptance of 
goods, partial acceptance of goods and rejection of goods at the invoice or receipt line item 

25 level can be included in the acknowledgment. These characteristics are tied to transaction 
levels involving users sponsored by the financial institutions (e.g., 230 or 240, shown by 
way of example). Where compliance before payment for a transaction is executed is to be 
ensured, this information is required to be verified a priori. An invoice or invoices for a 
particular transaction are updated with this and other transaction-fulfillment-related 

30 information. Using this approach, problems with received purchases, such as damaged 
goods, improper goods and improper financial terms are readily addressed. The various 
invoicing and payment-related characteristics are correspondingly modified (e.g., payment 



WO 2005/124635 



20 



PCT/US2005/020622 



is only made for accepted portions of goods, or credit for the cost of returning goods is 
granted, or payment is made using only accepted terms such as those relating to an accepted 
credit-related interest rate). 

In a more particular example embodiment, financial institutions approve financial 
5 contracts using a collaborative contract manager and submit order and invoice quantities for 
executing the contracts to the transaction processing system 210 (e.g., implementing a 
collaborative contract manager). The transaction processing system 210 then uses the terms 
from the collaborative contracts manager to establish financial processing terms (e.g., credit 
rate or other cost) between a user of financial services and the corresponding financial 

10 service provider. In one instance, financial service providers use the collaborative contracts 
manager as the central repository called by various provider systems. In another instance, 
the financial service user implements the collaborative contracts manager as the central 
repository called by various procurement systems. 

For general information regarding the implementation of transaction functions and 

1 5 for specific information regarding collaborative-type functions that can be implemented in 
connection with one or more example embodiments discussed herein, reference may be 
made to U.S. Patent Application Serial Nos. 10/436,878 (USBA.101PA) and 10/437,405 
(USBA.l 17PA), both filed on May 12, 2003 and fully incorporated herein by reference. 
In another embodiment, the transaction processing system 210 is configured for 

20 settling inter-bank issues relating to fees and/or other transaction characteristics. When a 
buyer and seller enter into a transaction, the transaction processing system 210 calculates 
the amount of funds to be collected from the buyer's sponsoring bank and remitted to the 
seller's sponsoring bank. These funds are used to fund the payment that the seller's 
sponsoring bank will make to the seller for all transactions that achieve payable status 

25 within a particular payment period (e.g. , a network day) for the transaction processing 
system's. 

Once the amount of funds to be collected are determined, the transaction processing 
system 210 further acts to facilitate the collection of these funds in one or more of a variety 
of manners. For instance, the transaction processing system 210 may simply make the 
30 amount of funds known to parties to the transaction using conventional communications 
methods. In other instances, the transaction processing system 210 actively facilitates 
collection of these funds. 
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In one example, an electronic payment demand is submitted on an interval (e.g. , at 
least daily) to the buyer's sponsoring bank for all net monies due either to the transaction 
processing system or to the seller's sponsoring bank when the buyer's sponsoring bank has 
net funds due. An electronic payment demand is also submitted on an interval to the seller's 
5 sponsoring bank for all net monies due either to the transaction processing system or to the 
buyer's sponsoring bank when the seller's sponsoring bank has net funds due. In addition, 
an electronic payment notice is submitted on an interval (e.g., at least daily) to the buyer's 
sponsoring bank for all net monies due to the buyer's sponsoring bank. The net monies due 
are contemplated after subtraction of funds due to either the transaction processing system 

10 or the seller's sponsoring bank when the buyer's sponsoring bank has net funds due. An 
electronic payment notice is also submitted to the seller's sponsoring bank for all net 
monies due to the seller's sponsoring bank. Similarly as above, these net monies due are 
contemplated after subtraction of funds due to either the transaction processing system or 
the buyer's sponsoring bank when the seller's sponsoring bank has net funds due. 

15 In connection with the various example embodiments discussed in connection with 

FIG. 2 (and otherwise), a fee engine is selectively implemented to facilitate the assessment 
of transaction processing fees. In some applications, the fee engine is implemented with a 
transaction processor (e.g., with transaction processing system 210), as a software- 
implemented engine. In this regard, fees such as those assessed in accordance with a 

20 business relationship between a financial institution and a buyer or seller party contracting 
therewith, or with a business relationship between a financial institution and an 
administrative transaction processor auditor, can be assessed using the fee engine. That is, 
the fee engine applies a fee appropriate for each transaction, and either directly or indirectly 
facilitates payment of that fee. 

25 Access to information at the database 220 is controlled in one or more of a variety of 

manners, with information made available to users selectively and in a variety of formats, 
depending upon the implementation. Various examples using this general approach are 
discussed below. These examples are selectively implemented with a data access controller 
216 and may involve approaches discussed above in connection with similar data access 

3 0 controller functions. 

In one example embodiment, each buyer-sponsoring financial institution and each 
seller-sponsoring institution has access to the transactions naming their sponsored buyer or 
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seller organization. By enabling such access, each financial institution is granted access to 
perform customer service functions related to transaction processing for their customers 
within the transaction processing system. These customer service functions may, for 
example, include the provision of accounting-relatqd data in an appropriate format and at a 
5 selected interval, or include providing a notification to the customer upon certain predefined 
events related to transaction processing and/or financial status of transactions or accounts. 
In addition, each financial institution can maintain an overview of their net position with 
each of their customers to whom they are issuing credit. The financial institution is 
presented a view into the transaction processing system that shows their customers 5 net 

1 0 position between payments due from customer and payments due to suppliers (through the 
transaction processing system). 

In another embodiment, each buyer- sponsoring financial institution has the 
capability, as enabled by user profiles stored at the database 220, to specify a variety of 
bank-specific operating characteristics. For example, each buyer-sponsoring financial 

1 5 institution may specify the financial institution that is to perform foreign currency 
translation on its sponsored buyer's behalf. This approach may be implemented, for 
example, where the seller desires to be paid in currency local to the seller and the buyer 
desires to be billed in currency local to the buyer. Each buyer-sponsoring financial 
institution may also specify a currency translation markup amount to add to translation 

20 services being provided to its buyers. The buyer-sponsoring financial institution may also 
specify the financial institution to use for remittance collection from its buyers. For general 
information regarding transaction processing, and for specific currency conversion 
implementations that may be implemented in connection with currency conversion as 
discussed here in connection with FIG. 2, reference may be made to U.S. Patent Application 

25 SerialNo. 11/104,394 (USBA.134PA), filed on April 12, 2005 and entitled "Automated 
Transaction Processing System and Approach with Currency Conversion," which is fully 
incorporated herein by reference. 

Seller-sponsoring institutions may also specify the financial institution(s) to use for 
delivering payments to the seller. For instance, one institution may be used for ACH 

30 origination for sellers holding US-domiciled bank accounts and another institution (e.g., a 
SWIFT institution) for European-based sellers, and another for Latin American-based 
sellers. 
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Financial institutions issuing credit to either the buyer or the seller can also specify 
where credit-related information is retrieved from for use in the transaction. For example, 
the location from which credit drawdown advice {e.g., relative to available credit in an 
appropriate credit account) is to be delivered can be specified. In addition, credit-issuing 
5 financial institutions can specify whether the drawdown advice is to include transaction 

details or simply be the aggregate of the transaction details for the reporting period. For the 
latter case, the transaction processing system 210 can be specified to be used as the detailed 
subledger to support the credit usage. In this sense, the transaction processing system 210 
functions much like conventional credit-issuing institutions (including credit card issuing 

10 institutions), with the credit issuer being provided summary or detail information. 

A variety of security-related functions are implemented with the transaction 
management system 210, depending upon the application and the desired level of security. 
For example, in some implementations, data flowing to the transaction processing system 
210 from sponsoring financial institutions (230, 240) are encrypted using standard 

1 5 encryption technologies. Similarly, data flowing from the transaction processing system 
210 to sponsoring financial institutions (230, 240) can also be encrypted using standard 
encryption technologies. Communications between any distributed computing devices and 
the transaction processing system 210 can also be encrypted using standard encryption 
technologies. For instance, where the various system implementations 1, 2 and N are 

20 employed at physically different locations, communication between these system 
implementations and the transaction management system 210 is encrypted. 

In addition to security-related functions for transaction communications, access to 
data within the transaction processing system 210 can also be controlled using security 
measures. For instance, profiles stored in the database 220 may include security type 

25 information, such as password and/or encryption information that users accessing the 
transaction management system 210 may employ. 

In some instances, the transaction processing system 210 addresses synchronization 
issues between various financial institutions and organizations, such as those discussed 
above, by implementing pricing and/or other transaction rules that have previously been 

30 agreed upon such that disputes over transaction price are typically eliminated. These rules 
may include, for example, criterion defining pricing data that can be automatically approved 
(e.g., transaction fees within a selected variance), and also control pricing information made 
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available to different users. The pricing rules may also include, for example, prices 
associated with particular transaction characteristics, with different prices being assigned for 
particular transactions (e.g., such as with a volume or amount discount). 

In various other example embodiments of the present invention, a credit-processing 
5 approach is implemented with a transaction management arrangement, such as that shown 
in FIG. 2 and discussed above. For example, the transaction processing system 210 can 
facilitate the extension of credit on behalf of one or more sponsoring financial institutions, 
or another financial institution, in connection with a particular user participant in a 
transaction. 

10 In one such credit-processing implementation, a buyer-sponsoring bank sponsors a 

buyer into the transaction processing system 210 and network with an active connection to a 
line of credit for usage within the transaction processing system and network. The buyer 
creates trading partner relationships with sellers who are sponsored into the transaction 
processing system 210, which facilitates the relationships and related transaction 

1 5 processing. When a buyer makes a purchase from a seller, the buyer sends an electronic 
copy of an order for the purchase to the transaction processing system 210 and network. 
The seller fulfills an order and issues an invoice electronically to the transaction processing 
system 210. 

Where particular events are to occur and/or conditions are to be met before an 
20 invoice becomes payable, these events or conditions are provided by an appropriate party to 
a transaction (e.g., buyer, seller or third party (such as customs or a freight forwarder)). 
These events and/or conditions can be specified using business rules as discussed above, 
with the transaction processing system 210 implementing the business rules. 

The transaction processing system 210 uses business rules and/or profiles for users 
25 to match incoming information such as order, invoice, receipt and/or event notices. This 
incoming information is audited and reconciled by the transaction processing system 210 
using appropriate business rules. For example, where a buyer establishes profiles, the 
transaction processing system 210 implements those profiles to audit and reconcile the 
information. 

30 Where payment is ripe as determined, e.g., via an audit as discussed above, and 

where payment is via the extension of credit, the transaction processing system 210 verifies 
that the extension of credit to the buyer and/or associated buyer party is appropriate. Where 
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the extension of credit is appropriate, the transaction processing system 210 sends 
authorization to the appropriate financial institution following rules established by that 
financial institution via profiles within the transaction processing system. 

When authorization is received and all other conditions required for payment are 
5 met, the transaction processing system and network electronically funds a seller with a 
single payment across all credit issuing institutions via a funds delivery pathway specified 
in the seller-sponsoring financial institution's profile. In some instances, the cost to the 
seller for this payment is varied based on the financial institution supplying the credit. The 
funds are delivered to the seller net of the seller-sponsoring bank's fees to the seller {e.g., 

10 fees are withheld prior to delivery of payment). The seller-sponsoring financial institution 
uses the pricing capabilities of the transaction processing system and network to compute 
and render the bill to the seller. Detailed data supporting the payment continues to be 
resident in the transaction processing system and network and does not add overhead to the 
banking industries money movement networks. 

15 In connection with the authorization above, the transaction processing system 210 

provides the buyer-sponsoring bank with a data feed that enables it to update its credit line 
to the buyer to acknowledge the draw down of that credit line to pay invoices. In some 
instances, the buyer-sponsoring bank will also use the transaction processing system 210 to 
calculate and render the invoice to the bank's buyer customer, and facilitates the linking of 

20 transaction data to the invoice. In these instances, the buyer-sponsoring bank provides the 
transaction processing system 210 with information for processing the invoice accordingly, 
in profile and/or business rule information. 

FIG. 3 shows a flow diagram for transaction processing involving the association of 
a particular financial institution with a transaction, according to another example 

25 embodiment of the present invention. At block 310, transaction data having financial 
transaction identification information is received from a user node. The financial 
transaction identification information may include identification data that pertains, for 
example, to a particular party to the transaction, to a financial institution or to other 
identification information specific to the particular transaction to which it applies. At block 

30 320, the financial transaction data is compared with financial institution identification data. 
If no match between the financial transaction data and a financial institution is found at 
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block 330, a failure notice is returned to a sender at block 335 indicating that the transaction 
cannot be processed. 

If a match between the financial transaction data and a financial institution is found 
at block 330, transaction processing data corresponding to the match is loaded at block 340. 
5 In some instances, this loaded transaction processing information includes information 
exclusively provided by a financial institution that is the subject of the match. In other 
instances, the loaded transaction processing data includes information for parties to the 
transaction in addition to the financial institution that is the subject of the match (e.g. , for 
specifying user preferences or profiles as discussed above). 

1 0 After the transaction processing data has been loaded, it is used to audit the 

transaction data at block 350 for facilitating financial aspects of the transaction. The audit 
generally involves parsing the financial transaction data using loaded processing data such 
as rules that can be implemented to specify whether the financial transaction data indicates 
that payment can be made. For instance, a price term engine can be used to derive a 

1 5 payment amount for the financial transaction, using information in the financial transaction 
data and in the loaded transaction data (e.g., specifying pre-agreed contract terms used in 
arriving at a price). Such a price term can be used for setting the price of one or more 
aspects of the financial transaction data. The audit is then used at block 360 to generate a 
payment term for the transaction, and the payment term is used to facilitate payment for the 

20 transaction. In this regard, the payment term may include one or more of a payment 

amount, a time of payment, a credit term, a method of payment or a source from where to 
draw the payment. 

While certain aspects of the present invention have been described with reference to 
several particular example embodiments, those skilled in the art will recognize that many 
25 changes may be made thereto without departing from the spirit and scope of the present 
invention, aspects of which are set forth in the following claims. 
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What is claimed is: 

1 . An automated transaction processing system and network for processing transactions 
for buyers and sellers sponsored into the processing network by a sponsoring bank, the 
system comprising: 

an association processor configured and arranged, for each of a plurality of 
transactions involving a buyer and a seller, to identify a particular sponsoring bank for each 
buyer and seller as a function of stored identifiers, the association identifying respective 
business rales, set in accordance with the particular sponsoring bank and the particular 
buyer or seller for which the rules are set, for respectively processing transactions on behalf 
of the buyer and on behalf of the seller for a particular transaction; and 

a collaborative contracts processor configured and arranged, for each particular 
transaction involving a buyer and a seller, to use the identified business rules and a business 
agreement between the buyer and seller to determine the amount of fees that 
should be charged to the seller, 

should charged to the buyer as a function of the identity of the buyer and the 

identity of the buyer's sponsoring bank, 

the seller's sponsoring bank owes the buyer's sponsoring bank, 
the buyer's sponsoring bank owes the seller's sponsoring bank, and 
the buyer's sponsoring bank and the seller's sponsoring bank owe the 

automated transaction processing system and network. 

2. The automated transaction processing system and network of claim 1 , further 
comprising a settlement processor configured and arranged, for each particular transaction 
involving a buyer and a seller, to: 

perform inter-bank settlement by calculating the amount of funds to be collected 
from the buyer's sponsoring bank and remitted to the seller's sponsoring bank to fund a 
payment that the seller's sponsoring bank will make to the seller for all transactions that 
achieve payable status within a payment period defined as a function of the business rules. 
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3. The automated transaction processing system and network of claim 2, wherein the 
settlement processor is configured and arranged, for each particular transaction involving a 
buyer and a seller, to: 

submit an electronic payment demand at a defined period to the buyer's sponsoring 
bank for all net monies due to at least one of the transaction processing system and the 
seller's sponsoring bank, when the buyer's sponsoring bank is in a net funds due to 
processor position; 

submit an electronic payment demand at a defined period to thjb seller's sponsoring 
bank for all net monies due to at least one of the transaction processing system and the 
buyer's sponsoring bank, when the seller's sponsoring bank is in a net funds due to 
processor position; 

submit an electronic payment notice at a defined period to the buyer's sponsoring 
bank for all net monies due the buyer's sponsoring bank after subtraction of funds due to at 
least one of the transaction processing system and the seller's sponsoring bank, when the 
buyer's sponsoring bank is in a net funds due to processor position; and 

submit an electronic payment demand at a defined payment period to the seller's 
sponsoring bank for all net monies due to the seller's sponsoring bank after subtraction of 
funds due to at least one of the transaction processing system and the buyer's sponsoring 
bank, when the seller's sponsoring bank is in a net funds due to processor position. 

4. The automated transaction processing system and network of claim 1, further 
comprising a data access controller configured and arranged, for each sponsoring financial 
institution, to: 

provide access to transactions naming a buyer or seller organization sponsored by 
the sponsoring financial institution; and 

maintain an overview of their net position with each of their customers to whom 
they are issuing credit, the overview showing each customer's net position between 
payments due from the customer and payments due to suppliers through the transaction 
processing system. 

5. The automated transaction processing system and network of claim 4, wherein the 
data access controller is further configured and arranged, for each sponsoring financial 
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institution, to perform customer service functions related to transaction processing for their 
customers within the transaction processing system, the customer service functions defined 
in the sponsoring financial institution's business rules in association with each customer. 

6. The automated transaction processing system and network of claim 1 , wherein the 
collaborative contracts processor is configured and arranged to implement profiles for each 
sponsoring financial institution for specifying bank-specific operating characteristics to use 
in processing transactions involving the sponsoring financial institution. 

7. The automated transaction processing system and network of claim 6, wherein the 
collaborative contracts processor is configured and arranged to perform a currency 
conversion using a financial institution to process the currency conversion as specified in 
the profile for a particular sponsoring financial institution. 

8. * The automated transaction processing system and network of claim 7, wherein the 
collaborative contracts processor is configured and arranged to assess a markup fee to a 
sponsored user as a function of profiles for the particular sponsoring financial institution's 
profile. 

9. The automated transaction processing system and network of claim 6, wherein the 
collaborative contracts processor is configured and arranged to use information in the 
profiles to identify a financial institution to use for remittance collection from buyers 
sponsored by the sponsoring financial institution. 

10. The automated transaction processing system and network of claim 6, wherein the 
collaborative contracts processor is configured and arranged to use information in the 
profiles to identify a financial institution that the sponsoring financial institution specifies to 
use for payments to each seller sponsored by the sponsoring financial institution. 

1 1 . The automated transaction processing system of claim 10, wherein the collaborative 
contracts processor is configured and arranged to use information in the profiles to identify 
a financial institution that the sponsoring financial institution wants to use for payments to 
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each seller sponsored by the sponsoring financial institution, as a function of a geographical 
location of each seller. 

12. The automated transaction processing system and network of claim 6, wherein the 
collaborative contracts processor is configured and arranged to use information in the 
profiles to identify a location to which credit drawdown advice is to be delivered and to 
specify the content of the credit drawdown advice 

1 3 . The automated transaction processing system and network of claim 1 , further 
comprising a data storage arrangement configured and arranged for storing all transaction 
data for transactions involving sponsored buyers and sellers, and to provide access to all of 
the transaction data to the collaborative contracts processor. 

14. The automated transaction processing system and network of claim 13, wherein the 
data storage arrangement includes at least two different databanks connected via a network 
link. 

1 5 . The automated transaction processing system and network of claim 1 , wherein the 
association processor is configured and arranged to identify a particular set of business rules 
to implement for a particular transaction as a function of a credit term associated with the 
particular transaction. 

1 6. The automated transaction processing system and network of claim 1 , wherein the 
association processor is configured and arranged to identify a particular set of business rules 
to implement for a particular transaction as a function of the geographic location of at least 
one party to the particular transaction. 

17. The automated transaction processing system and network of claim 1, wherein the 
association processor is configured and arranged to identify a particular set of business rules 
to implement for a particular transaction as a function of historical information associated 
with at least one party to the particular transaction. 



WO 2005/124635 



31 



PCT/US2005/020622 



18. The automated transaction processing system and network of claim 1, wherein the 
association processor is configured and arranged to store and implement identifiers to 
identify a particular sponsoring bank for each of the buyer and seller by storing and 
implementing user profiles for each buyer and seller, the user profiles specifying the 
identifiers that identify a particular sponsoring bank for each buyer and seller. 

19. The automated transaction processing system and network of claim 1 8, wherein the 
association processor is configured and arranged to store and implement user profiles, for 
each buyer and seller, that specify a non-sponsoring financial institution that the buyer or 
seller wishes to use with the transfer of funds for transactions. 

20. The automated transaction processing system and network of claim 19, wherein the 
association processor is configured and arranged to select a store and implement user 
profiles, for each buyer and seller, that specify a non-sponsoring financial institution as a 
function of at least one of: the amount of a particular transaction, the type of a purchase 
associated with the transaction, the location of a purchase associated with the transaction^ 
taxes on the transaction, the interest rate available from the financial institution, and 
insurance for the transaction. 

21 . The automated transaction processing system and network of claim 1, wherein the 
collaborative contracts processor configured and arranged, for each particular transaction, to 
use the identified business rules to select ACH (automatic clearing house) outbound 
payment & facilitation functions to implement for each particular transaction. 

22. A method for auditing transactions between contracting parties on behalf of a 
plurality of financial institutions, the method comprising: 

associating each transaction with a unique one of the plurality of financial 
institutions; 

auditing each transaction according to a set of transaction rules defined as a function 
of the unique financial institution and a business relationship between the unique financial 
institution and at least one of the contracting parties, and 

facilitating payment for each transaction as a function of the audit. 
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23. The method of claim 22, further comprising, for each transaction, defining a set of 
transaction rules for a unique financial institution associated with the transaction as a 
function of the unique financial institution and a business relationship between the unique 
financial institution and at least one of the contracting parties. 

24. A system for auditing transactions between contracting parties on behalf of a 
plurality of financial institutions, the system comprising: 

means for associating each transaction with a unique one of the plurality of financial 
institutions; 

means for auditing each transaction according to a set of transaction rules defined as 
a function of the unique financial institution and a business relationship between the unique 
financial institution and at least one of the contracting parties, and 

means for facilitating payment for each transaction as a function of the audit. 

25. A method for processing transactions for buyers and sellers sponsored into a 
processing network by a sponsoring bank, the method comprising: 

for each of a plurality of transactions involving a buyer and a seller, identifying a 
particular sponsoring bank for each buyer and seller as a function of stored identifiers, the 
association identifying respective business rules, set in accordance with the particular 
sponsoring bank and the particular buyer or seller for which the rules are set, for 
respectively processing transactions on behalf of the buyer and on behalf of the seller for a 
particular transaction; and 

for each particular transaction involving a buyer and a seller, use the identified 
business rules and a business agreement between the buyer and seller to determine the 
amount of fees that 

should be charged to the seller, 

should charged to the buyer as a function of the identity of the buyer and the 

identity of the buyer's sponsoring bank, 

the seller's sponsoring bank owes the buyer's sponsoring bank, 
the buyer's sponsoring bank owes the seller's sponsoring bank, and 
the buyer's sponsoring bank and the seller's sponsoring bank owe the 

automated transaction processing system and network. 
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